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APPEAL BRIEF UNDER 37 CFR § 41.37 

I, Real Party in Interest 

Sun Microsystems, Inc. 
4120 Network Circle 
Santa Clara, CA 95054 
USA 

IL Related Appeals and Interferences 

No other appeals or interferences are currently known to Appellants that will directly 
affect, be directly affected by, or have a bearing on the decision to be rendered by the Board 
of Patent Appeals and Interferences in the present appeal 

III- Status of Claims 

Claims 1-6, 8-12, and 14-46 are pending in the application, with claims 7 and 13 
being cancelled. No claims have been allowed, and all pending claims stand rejected under 
35 U.S.C. §102. The rejection of claims 1-6, 8-12, and 14-46 is the subject of this appeal. 
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IV, Status of Amendments 

Appellants filed an Amendment on March 14, 2006 that included an amendment to 
claim 1 to further clarify the term "assignments" that are assigned to registered applications 
and to correct an error in independent claim 34, In the Advisory Action, the Examiner failed 
to indicate whether or not these claim amendments would be entered for purposes of appeal 
However, the Continuation Sheet indicates that the further clarification of claim 1 would 
require a new search. Hence, Appellants are filing this Appeal Brief under the assumption 
that the amendments were not entered by the Examiner. 

Claims l-6 ? 8-12, and 14-46 are provided in the attached Claims Appendix, with 
claims 1 and 34 being shown in their current states (i.e., without entry of the March 14, 2006 
Amendment). 

V. Summary of Claimed Subject Matter 

Claims 1, 18, 25, 30, 33, 34, 36, 40, and 41 are independent claims that are being 
appealed. 

Claim 1 is directed to a method for managing high-avail ability- aware applications in a 
networked computer system (such as systems of Figures 1,2,3, 5, and 10). High-availability 
aware components, which may include software as noted in paragraph [0028], is described in 
paragraph [0029] as applications that "are aware of their execution in a highly available 
environment. . .they are capable of cooperating and complying with the highly available 
environment," Figure 2 illustrates a networked computer system 200 in which a CRIM 
(component role and assignment management system or module) 201 acts to allocate roles 
and assignments of registered applications such as high-availability aware applications 204a, 
204b, 204c, 202a, 202b, 203a, 203b. The description of application or component "states," 
"assignments," "roles," "types," and "categories" and how each of these are managed by a 
CRIM, such as CRIM 201 of Figure 2, is provided in paragraphs [0029] to [0054]. 

As called for in claim 1, the method includes "invoking a registration application 
programming interface by the plurality of high-availability-aware applications to be 
managed," The high-availability (HA) aware applications may be any of the applications 
shown in the figures such as applications 204a, 204b, 204c ; 202a, 202b, 203a, 203b of Figure 

? 



2 (or those discussed with reference to Figures 7- 10b), The operations of the CRIM with 
relation to managing applications to achieve high availability and levels of redundancy is 
explained in the specification beginning at paragraph [0055] with specific examples being 
provided with reference to Figures 2 and 7-9, Further, the "interfaces" that may be utilized 
by the applications are discussed in detail in the specification in paragraph [0073] and Table 

3 on page 27. 

In this regard, the method of claim 1 further calls for "invoking callback interfaces of 
registered applications to dynamically allocate roles and assignments to one or more of 
registered applications . . .to achieve a desired redundancy level based on application type 
information." Such invoking of interfaces can be readily seen in the discussion of the 
interfaces in paragraph [0073] and Table 3 and the general operation of the CRIM (e.g, 5 
CRIM 201 of Figure 2 or CRIM 500 of Figure 5) as noted above. 

As stated in Appellants' November 10, 2005 Amendment, the invention can be 
concisely summarized as "a method and system to ensure that HA-aware systems recover 
from failure with little to no impact on the user. One approach employed by the Applicants is 
to use, allocate, and efficiently manage redundant systems based on several criteria. To 
accomplish this, the invention disclosed and claimed by the Applicants registers HA-aware 
components and determines a redundancy level based on the component type information. 
Once registered, the Applicants' invention allocates assignments to a predetermined number 
of secondary components selected from the registered components based on component type 
information. This redundancy level provides a degree of preparation and planning to act 
quickly, efficiently, and seamlessly when failures occur" (with support for these statements 
found in the above-cited paragraphs of the specification). 

Independent claim 1 8 is directed to a method of allocating an assignment in a 
networked computer system, and the explanation of the invention of claim 1 is applicable to 
claim 18. Specifically, claim 1 8 calls for "registering a plurality of components applications 
through an application programming interface," and this registering is typically performed by 
a CRIM (such as CRIM 201 of Figure 2) as noted in paragraph [0065]. Then roles and 
assignments are allocated and changed using callback interfaces as discussed with reference 
to claim 1 and the operation of a CRIM of the invention. The changing and allocation of 
roles and assignments in claim 18 is performed to achieve a determined "application specific 
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redundancy level," which can be understood with reference to Figure 8 and the example of 
the use of assignments based on types of applications or components (see paragraphs [0060] 
to [0062]). 

Independent claim 25 is directed to a method similar to that of claim 1 8 but brings in 
the idea of 'maintaining relationship information" and selecting among applications for 
assignment/roles based on their relationship information and application type information. 
The management of relationships managed by a CRIM is described in detail in the 
specification in paragraphs [0101] to [01 12], 

Independent claims 30 and 33 are directed to a computer program product and 
readable medium, respectively, with limitations similar to that of the method of claim 1 but in 
differing form. As a result, the description provided for claim 1 is believed applicable to 
claims 30 and 33, 

Independent claim 34 is directed to a computer program product with limitations 
similar to that of the method of claim 1 8 but in differing form. Hence, the explanation of the 
invention of claim 18 is believed applicable to claim 34. 

Independent claim 36 is directed to a system for managing a plurality of HA-aware 
applications. The limitations to the claims include limitations similar to claim 1 (i.e., the 
explanation of claim 1 applies to claim 36) but that are written in means plus function format. 
The means for registering the applications is related to the structure of the interfaces 
described in Table 3 and related portions of the specification, the HA-aware applications 
(such as applications 204a 3 204b, 204c, 202a, 202b, 203a, 203b of Figure 2 and the other 
applications or components shown in the other figures and described in the specification), and 
the CRIMs (such as CRIMs 200 and 500 and the like and other CRIMs described in the 
specification). The means for dynamically allocating roles and assignments to the registered 
applications to achieve a desired redundancy level is related to the structure of the CRIMs 
described in the text and related/corresponding elements and to interfaces of the applications 
as described at least in Table 3. 

Likewise, independent claim 40 is directed to a system with limitations similar to 
those of the method of claim 18. The limitations are written in means plus function format 
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with the functions being similar to the method limitations of claim 18. The structure for each 
of the limitation is related to the CRIM systems or modules described in the specification 
considered alone or more typically in relation to the HA-aware applications (e.g., applications 
204a ? 204b ? 204c, 202a, 202b ? 203a ? 203b of Figure 2 and other HA-aware applications or 
components of the Figures and related text) and the interfaces of Table 3 and related text. 

Independent claim 41 is directed to a mechanism with limitations similar to that of 
claim 1 but written in apparatus form. The explanation of claim 1 is applicable to claim 41 . 

VI. Grounds of Rejection to be Reviewed on Appeal 

Claims 1-6, 8-12, and 14-46 stand rejected under 35 US.C § 102(e) as being 
anticipated by US, Pat. No. 6,766,348 (-Combs"). 

VII* Argument 

Rejection of Claims 1-6, 8-12, and 14-46 Under 35 U,S.C, §102(e) Based on Combs is 
Improper 

In the final Office Action of January 30, 2006, claims 1-6, 8-12 and 14-46 were 
rejected under 35 US.C. § 102(e) as being anticipated by Combs. This rejection is traversed 
based on the following remarks, and Appellants request that the rejection be reverse as not 
properly supported. 

Much of the following discussion was provided in Appellants' March 14, 2006 
Amendment, which was filed in response to the final Office Action of January 3Q ; 2006. 
However, it is being repeated in a substantially unchanged form because there is no 
indication in the record that it has yet been considered by the Examiner. Much of the 
discussion or remarks (e.g., that Appellants' claimed invention is directed to providing levels 
of redundancy for software applications rather than hardware components or resources) were 
first provided in the March 14, 2006 Amendment, but the Advisory Action only stated that 
the claim amendments would not be entered as requiring a new search. 

However, it should be understood that the following arguments were in large part 
describing differences between claim language and the teaching of Combs based on a claim 
amendment entered as part of the filing of a Request for Continued Examination (RCE) on 
June 28 5 2005, Appellants believe the claim amendments entered with the RCE distinguished 
each of the pending claims from Combs because Combs fails to teach the managing of 



software components or applications to achieve a desired software or application-based 
redundancy as called for in the claims. 

Initially, as discussed in the March 14, 2006 Amendment, it may be useful to 
understand a few of the large differences between the teaching of Combs and the invention 
being claimed by Appellants. In an amendment entered with the RCE of June 28, 2005, the 
term ' 'applications" was inserted into the independent claims (rather than the broader term 
"components") to clarify that the invention was directed toward managing a plurality of high- 
availability-aware applications (or software components) rather than hardware. In a first 
Office Action after the RCE mailed on August 24, 2005, the Examiner withdrew the use of a 
reference that was directed toward managing "nodes" (Le,, U.S. Pat. No. 6,633,538 or 
Tanaka), 

However, Combs was then cited in place of Tanaka for teaching each and every 
limitation of the pending claims. However, Combs differs significantly from the claimed 
invention and does not even suggest Appellants claimed invention. Combs teaches the use of 
a number of agents ("resource allocator system agents" or "RASAs" that form a resource 
allocator handling system" or "RAHS") to provide load balancing of hardware resources. 
Combs teaches that "users" (elements 107-1 10 in Fig. 1) access resources (elements 112-118 
of Fig. 1 which may be "printers, modems, switchboards, or other electronic devices," see 
col, 1, lines 53-65). The resources are not described as software components or applications. 
The resources are registered with the RAHS, and to use a resource, a user transmits requests 
to a RASA, which acts to provide load balancing of the use of the resources through 
communications with other RASA in the RAHS (and by maintaining a table or database of 
information on the resources). There is no teaching in Combs that the "users" or applications 
running in the computer system are registered or that these users have roles and assignments 
dynamically allocated to achieve redundancy in the system as called for in the pending 
independent claims. Hence, it appears that there are significant differences between the 
system of Combs and the methods and systems claimed by Appellants. 

Specifically, claim 1 calls for invoking a registration application programming 
interface by applications and then dynamically allocating roles and assignments to the 
registered applications to achieve a desired redundancy level based on application type 
information. In Combs, the only components providing processing functionality and the like 
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are the users, and there is no discussion of registering these users. Instead, Combs teaches 
that the resources or hardware devices are registered with the RAHS (for example, see Fig. 
12 of Combs). The January 30, 2006 Office Action cites col. 4, lines 16-39 in which the 
resource allocator tracks resource usage by users for teaching the registration feature of claim 
1, but, at this citation, Combs fails to teach registering a plurality of high-availability-aware 
applications as called for in claim 1, The cited portion of Combs discusses information 
exchange among the RASAs and to users that request resources but does not discuss 
registering the hardware resources let alone the users for management. Further, there is no 
discussion of "invoking a registration application programming interface" by the applications 
to achieve registration. Hence, the first "invoking" element of claim 1 is not shown or 
suggested by Combs. 

Further, the second "invoking" element of claim 1 calls for invoking callback 
interfaces of the registered applications to "dynamically allocate roles and assignments" to 
the applications. There is no suggestion in Combs that the users or other applications are 
dynamically allocated roles and assignments. The users provide a static functionality in the 
Combs system and their roles and assignments are not changed by the RAHS. The Office 
Action cites Combs at col, 4, lines 1-39 for teaching this limitation, but at this citation and 
elsewhere, Combs discusses managing the hardware resources and making them available to 
the users ("applications" for arguments sake). There is no discussion that such hardware 
resources may be allocated an "assignment" (e.g., an assignment as defined in Appellants' 
specification as being used to specialize a software applications functionality). Additionally, 
there is no discussion that applications within the Combs system are allocated "roles" such 
that might, for example, define their availability state as discussed in Appellants' 
specification. The RASA are agents or applications, but they are not managed through 
registration and dynamic allocation of assignments and roles as called for in claim 1 k Hence, 
the second "invoking" element of claim 1 is not shown or suggested by Combs, and 
Appellants request that the rejection be withdrawn. 

Further, as discussed in the Amendment of November 10, 2005, independent claim 1 
recites, among other things, "invoking callback interfaces of registered applications to 
dynamically allocate roles and assignments to one or more of registered applications of the 
plurality of high-availability-aware applications to achieve a desired redundancy level based 
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on application type information/' Combs fails to disclose the establishment of a redundancy 
level based on application type information nor does Combs disclose allocation of roles and 
assignments to achieve a redundancy level. 

With regard to these arguments, the Office Action of January 30, 2006 in the 
Response to Arguments asserts that redundancy is obtained in the RAHS of Combs because 
there is mirroring and redundancy of the RASAs, However, claim 1 calls for the dynamic 
allocation of roles and assignments to be performed to "achieve a desired redundancy level" 
and Combs does not allocate roles and assignments to the RASA to obtain redundancy. 
Instead, availability is managed/tracked for resources by the RASAs, and there is no 
discussion of "assignments" as defined in claim L 

Further, as discussed at page 3 of the November 10, 2005 Amendment, Combs 
appears to disclose a "system for exchanging data between a user and a distributed resources 
allocation handling system that allocates computer resources.. (see, Combs at coL % lines 
38-41). The system described in Combs employs a resource allocation system agent that 
"communicate one with another using a difference communication protocol. The elements of 
the resource allocation handling system provide an efficient load balance mechanism that 
allocates resources to users on the basis of similar domain and greatest remaining capacity. 57 
(see, Combs at col. 2, lines 57-62 with emphasis added) Put succinctly, Combs "provides a 
method of load balancing a plurality of resources in a distributed resource allocation system 
operating across a plurality of domains within a computer network," (see, Combs at col. 2, 
line 66 - col 3, line 2) The method of claim 1 manages high-availability-aware ("HA- 
aware") components by first registering the components and then dynamically allocating 
roles and assignments to one or more of the components to achieve a desired redundancy 
level based on component type information . These claim elements are lacking in Combs, and 
for this additional reason, Combs fails to support an anticipation rejection of claim L 

Claims 2-6, 8-12, and 14-17 depend from claim 1 and are believed allowable over 
Combs at least for the reasons provided for allowing claim 1 . 

Independent claim 18 is directed to a method similar to claim 1 s and hence, the 
reasons for allowing claim 1 over Combs are believed applicable to claim 18. Specifically, 
claim 18 calls for "allocating roles" to registered applications and allocating an assignment to 
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the application and also changing a role of the application. As discussed with reference to 
claim 1, Combs fails to teach allocating roles and assignments to the users or other 
applications in its description or figures. 

Further, claim 18 calls for "determining an application specific redundancy level 
based on the application type information," The January 30 ? 2006 Office Action appears to 
argue that the provision of multiple RASAs provides such a determining/redundancy. 
However, claim 1 8 calls for the redundancy to be application specific and this is not shown 
or suggested by Combs, with this reference, as discussed with reference to claim 1, not being 
concerned with redundancy in the users/applications. 

Additionally, the final two claim elements of claim 1 8 describe specific role and 
assignment processes that are not shown in Combs. In the Amendment of March 14, 2006, 
Appellants specifically asked the Examiner "where does Combs teach allocating a particular 
assignment to a number of secondary applications to achieve a redundancy level?" No 
response was provided in the most recent Advisory Action, The Response to Arguments in 
the January 30, 2006 Office Action implies that since the RAHS can survive failure of a 
resource or a RASA that it provides this type of redundancy, but Combs does not teach that 
redundancy for a user is determined and then based on such determination that additional 
users are allocated a particular assignment to achieve redundancy. Hence,, each and every 
element of claim 18 is not shown by Combs, 

Claims 1 9-24 depend from claim 1 8 and are believed allowable at least for the reasons 
for allowing claim 18, 

Independent claim 25 is directed to a method with limitations similar to those of claim 
1 8, and hence, the reasons provided for allowing claim 18 are believed applicable to claim 
25. Further, claim 25 calls for "maintaining application relationship information," "selecting 
a first application from the registered applications based on application type information and 
application relationship information," and "determining a redundancy level based on the 
application type information," Combs fails to show these limitations of claim 25. The 
January 30, 2006 Office Action cites Combs at col. 9, lines 17 to coL 10, lines 40 and col. 4 5 
lines 1-40 for teaching these limitations (and all others of claim 25), but at these citations, 
Combs fails to show the determination of a redundancy level based on application type 
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information, with Appellants' explaining exemplary application types beginning at paragraph 
[0047] of their specification. 

Providing redundancy in the RASAs is not the same as determining redundancy levels 
for particular software application types, Combs at this citation also does not show 
maintaining application relationship information or selecting an application based on such 
information. In the March 14, 2006, Appellants asked the Examiner "where does Combs 
teach maintaining relationship information for the users/applications"? Again, no answer was 
provided in the recent Advisory Action. For these additional reasons, claim 25 and claims 
26-29, which depend from claim 25, are believed allowable over this reference. 

Independent claims 30 and 33 are directed to computer program products/medium 
with limitations similar to claim 1 and are believed allowable for the reasons provided for 
allowing claim 1. Claims 3 1-32 depend from claim 30 and are believed allowable as 
depending from an allowable base claim. 

Independent claim 34 is directed to a computer program product with limitations 
similar to claim 18 and is believed allowable over Combs for the reasons provided for 
allowing claim 18. Claim 35 depends from claim 34 and is believed allowable at least for the 
reasons for allowing claim 34. 

Independent claim 36 is a system claim with limitations similar to claims 1, 30, and 
33 and is believed allowable for the reasons provided for allowing these claims. Claims 37- 
39 depend from claim 36 and are believed allowable for at least the reasons provided for 
allowing claim 36. 

Independent claim 40 is a system claim with limitations similar to claims 18 and 34 
and is believed allowable for the reasons provided for those claims. 

Independent claim 41 is directed to an apparatus with limitations similar to claim 1, 
and hence, the reasons provided for allowing claim 1 are believed equally applicable to claim 
41 . Claims 42-46 depend from claim 41 and are believed allowable over Combs for at least 
the reasons provided for claim 41. 
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Conclusion 



In view of all of the above, claims 1-6, 8-12, and 14-46 are believed to be allowable 
and the case in condition for allowance. Appellants respectfully request that the Examiner's 
rejections based on 35 U.S.C. §102 be reversed for all the pending claims. 



Date : May 31,2006 




Kent A. Lembkef Reg. No. 44,866 
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